Message-based communications

ABSTRACT

According to one aspect of the present invention, there is provided a method of communicating information between an intermediate element and a source element in a message-based communications system in which a request message is sent from the source element to a destination element and in response to which a corresponding response message is sent from the destination element to the source element, the request and response messages being sent via an intermediate element arranged to forward the messages to the appropriate element, comprising, at the intermediate element: prior to forwarding a received request message: determining the presence, in the received request message, of an indication of the information to be communicated and where present, adding a temporary identifier associated with the intermediate element to the message in such a way that the temporary identifier is included in the corresponding response message; and prior to forwarding a received response message: determining the presence of a temporary identifier associated with the intermediate element and, where present, replacing the temporary identifier with the information to be communicated to the source element.

The present invention relates generally to the field of communicationsprotocols and systems and, more particularly, to message-basedcommunications in which messages are communicated between end points viaone or more intermediate element.

Many communication systems use a request-response message-basedcommunications protocol for communicating between a source element and adestination element. Often request and response messages are sent via anintermediate element which forwards received messages to the appropriatedestination element.

Session Initiation Protocol (SIP) is one example of such acommunications protocol and which is defined in Request for Comments(RFC) 3261 as an application-layer control and signaling protocol forestablishing, modifying, and terminating real-time calls and conferencesover, primarily, Internet protocol (IP) networks. These actions areeffected by sending requests and receiving responses, in the form of SIPmessages, from one SIP element to another.

In some circumstances it may be necessary for an intermediate element tocommunicate information to a source element, however there may not existany direct two-way communication path between an intermediate elementand a source element. In such cases, the only way for an intermediateelement to communicate information with a source element is to wait fora response message to be sent from the destination element, and which isalso sent via the intermediate element, and to add the information to becommunicated to the response message. Where an intermediate elementreceives messages from multiple source and destination elements amechanism is additionally required to enable the intermediate element todetermine which response messages are associated with which requestmessages. In SIP such a situation arises with use of SIP messagecompression, in which the information to be communicated relates tomessage compression, as defined in RFC 3486. RFC 3486 describes how SIPmessages may be compressed and provides a parameter which can be addedto a SIP message to indicate whether an element supports the SIPcompression.

For example, a SIP request message sent from a source element to adestination element via an intermediate element may contain informationindicating that the source element supports SIP compression. If theintermediate element also supports compression, then information mayneed to be communicated back to the source element in order to allowfuture communications between the source and the intermediate element totake place using compression. The intermediate element achieves this by,upon receiving a corresponding response message sent by the destinationelement to the source element, inserting information in the message forindicating to the source element that the intermediate element alsosupports compression.

Since an intermediate element, such as a SIP proxy, will typicallyreceive messages from multiple destinations a context database needs tobe maintained to enable the intermediate element to pair upcorresponding request and response messages forming part of the sametransaction. Such techniques, for example as described in RFC 3486,require intermediate elements, such as proxy servers, in the messagepath to locally store dialog or transaction context information—in otherwords, the currently proposed techniques require use of statefulelements.

Stateful elements require the provision of additional storage capacity,databases, look-up routines, garbage collection routines and the like,which use up valuable processing resources and typically increase thecost and development times of such devices. In SIP, for example,compression enabled proxy servers are often located at the gatewaybetween fixed and wireless networks and are generally critical networkelements requiring both high performance and high availability.

As will be appreciated by those skilled in the art, the requirement tomake an element highly available, especially where large amounts ofcontext data needs to be preserved, is difficult and costly.Furthermore, the provision of high-availability mechanisms typicallyleads to some reduction in performance, which is particularlyundesirable in telecommunications applications, for example, where thenumber of simultaneous calls which may be handled by an element, andwhich is often a significant distinguishing factor between competitorproducts, is directly related to the performance of the system.

Accordingly, one aim of the present invention is to mitigate at leastsome of the above-mentioned problems.

According to a first aspect of the present invention, there is provideda method of communicating information between an intermediate elementand a source element in a message-based communications system in which arequest message is sent from the source element to a destination elementand in response to which a corresponding response message is sent fromthe destination element to the source element, the request and responsemessages being sent via an intermediate element arranged to forward themessages to the appropriate element. The method comprises, at theintermediate element, and prior to forwarding a received request messageof determining the presence, in the received request message, of anindication of the information to be communicated and where present,adding a temporary identifier associated with the intermediate elementto the message in such a way that the temporary identifier is includedin the corresponding response message. Prior to forwarding a receivedresponse message the method comprises: determining the presence of atemporary identifier associated with the intermediate element and, wherepresent, replacing the temporary identifier with the information to becommunicated to the source element.

Advantageously this removes the need to store message related contextinformation and thus removes the need for associated database lookuproutines, garbage collection routines and the like.

Suitably the temporary identifier is unambiguous within the system.

Suitably the step of adding the temporary identifier further comprisesadding additional information for identifying the type of information tobe communicated to the source element.

The message-based communication system may be a session initiationprotocol (SIP) based system, wherein the intermediate element is a SIPproxy server, in which case the request message may be a SIP requestmessage, and wherein the response message may be a SIP response message.In this case, the step of determining the presence in the receivedrequest message further comprises determining the presence of a SIPcompression parameter.

The request message suitably includes the URI of the SIP proxy, and thenthe step of adding the temporary identifier further comprises adding thetemporary identifier to the URI of the SIP proxy.

Suitably the step of determining the presence of the temporaryidentifier in a response message further comprises determining thepresence of the temporary identifier in the URI of the SIP proxy withinthe response message.

Preferably the step of replacing the temporary identifier furthercomprises replacing the temporary identifier with a SIP compressionparameter.

Suitably future request messages from the source element to the SIPproxy are sent using compression where the SIP proxy has previouslyindicated to the source element that the proxy supports SIP compression.

According to a second aspect of the present invention there is providedan intermediate element adapted for operating in accordance with any ofthe above described method steps.

According to a third aspect of the present invention there is provided aSIP proxy adapted for operating in accordance with any of the abovedescribed method steps.

According to a fourth aspect, there is provided apparatus for forwardingmessages in a message-based communications system in which a requestmessage is sent from a source element to a destination element and inresponse to which a response message is sent from the source element tothe destination element, the system being arranged such that messagesare sent via the apparatus for forwarding to their appropriatedestination, comprising means for, prior to forwarding a receivedrequest message, determining in the received request message thepresence of an indication of the information to be communicated, saidmeans being arranged for, where the presence of the indication isdetermined, adding a temporary identifier associated with theintermediate element to the message in such a way that the temporaryidentifier is included in the corresponding response message; and meansfor, prior to forwarding a received response message, determining in thereceived response message the presence of a temporary identifierassociated with the intermediate element, said means being arranged for,where the presence of the temporary identifier is determined, replacingthe temporary identifier with the information to be communicated to thesource element.

An embodiment of the present invention will now be described, by way ofexample only, with reference to the accompanying diagrams, in which:

FIG. 1A is a block diagram showing a SIP network according to the priorart;

FIG. 1B is a message flow diagram outlining a typical message flowbetween the different network elements of the network shown in FIG. 1A;

FIG. 2A is a block diagram showing a SIP network including a SIP proxyserver according to an embodiment of the present invention;

FIG. 2B is a message flow diagram outlining a message flow between thedifferent network elements of the network shown in FIG. 2B; and

FIG. 3 is a flow diagram outlining example processing steps performed bya SIP proxy server in accordance with an embodiment of the presentinvention.

The following description is made with reference to session initiationprotocol (SIP) networks. However, it will be understood by those skilledin the art that the inventive concepts described herein are in no waylimited to SIP, and may be used, with appropriate modification asrequired, with other communications protocols having similarcharacteristics.

FIG. 1A shows a block diagram of a typical SIP network 100 according tothe prior art. The SIP network comprises a number of network elements,namely a SIP user agent client (UAC) 102, a SIP user agent server (UAS)110, and a number of intermediate elements, such as SIP proxy servers,104, 106 and 108. The UAC 102 may establish a call, for example, withthe UAS 110 by sending a request message, such as an INVITE message, tothe UAS 110. The UAS may respond with a response message, such as a 200OK message, as is described in further detail below. As will beappreciated by those skilled in the art, additional messages may also besent in order to complete the call set-up.

In SIP, such an exchange of messages is known as a transaction, with atransaction comprising all messages from the first request message sentfrom a server up to a final (non-1xx) response message sent from theserver back to the client. A SIP call is defined as comprising allmessages from an initial INVITE message up to a BYE message. A SIP callmay comprise multiple transactions.

The proxy servers 104, 106, and 108 are used to route messages, in aknown manner. In this example, the UAC 102 and the proxy server 106support SIP message compression according to RFC 3486, whilst the othernetwork elements do not.

Referring now to FIG. 1B, there is shown a message flow diagram showingthe initial messages involved in setting up a call between the UAC 102and the UAS 110. Those skilled in the art will appreciate thatadditional messages may also be involved in a call set-up. For claritythe messages shown in FIG. 1B are shown in abbreviated form and showonly some of the available SIP message headers.

The UAC 102 sends a SIP INVITE message 120 to the UAS 110. The INVITEmessage 120 is initially sent to a proxy server 104 the address of whichis preconfigured in the UAC 102. The Contact header of the INVITEmessage 120 contains the universal resource indicator (URI) of the UAC102. As previously mentioned, the UAC 102 supports SIP messagecompression so, in accordance with RFC 3486, the UAC 102 adds theparameter comp=sigcomp to its URI in the Contact header. The value whichcomp may take indicates the type of compression scheme to be used.Hereinafter it is assumed that the Signaling Compression (SigComp)scheme defined in RFC 3320 is used, however the actual compressionmechanisms are outside of the scope of the present invention and willnot be discussed further. For clarity, hereinafter the shorthandnotation comp is used in place of the longhand notation comp=sigcomp.The presence of the comp parameter in the URI of the SIP message headeris used to indicate both that a particular element supports compressionand that that element wishes to receive future messages in compressedformat, where possible.

It is also possible for the UAC 102 to be preconfigured to send initialmessages in compressed form if the UAC 102 knows that the proxy 104 alsosupports compression.

Since the UAC 102 does not know, at this stage at least, whether anyother elements in the SIP network support SIP message compression theUAC 102 initially sends messages uncompressed, after having added a Viaheader to the message 120 with the URI of the UAC 102.

SIP proxy 104, which does not support SIP compression and is thusstateless, receives the INVITE message 120 and forwards the message,after having added its URI to the list of Via headers, to the SIP proxy106.

SIP proxy 106, which supports SIP compression, receives the INVITEmessage 122. The proxy 106 is configured to stay in the path of futurerequests in the same SIP dialog and achieves this by adding aRECORD-ROUTE header containing its URI to the message. Since the proxy106 supports compression it stores information in a transaction contextdata store. The type of information stored includes the Contact URI,unique call identification, and other information which can be used bythe proxy to match up the current request with an eventual responsemessage. Additional information is stored to indicate whethercompression should be used when communicating with different SIPelements. Proxy 202 is thus said to be a stateful proxy. Finally, theproxy 106 adds its URI to the list of Via headers, and forwards themessage 124 uncompressed to the SIP proxy 108, since again proxy 106does not initially know if proxy 108 supports compression.

SIP proxy 108, which in this example does not support compression and isthus stateless, receives the INVITE message 124 and, as it too wishes tostay in the path for future requests in the same dialog, adds aRECORD-ROUTE header containing its URI to the message and adds its URIto the top of the list of Via headers. The message is sent to UAS 110uncompressed since the proxy 108 does not know if the UAS supports SIPcompression.

The UAS 110 receives and processes the message 126 in the usual manner.Since the INVITE message is the first message of a call, the UAS 110constructs and stores a ‘route set’ as part of the current call context.A route set is a collection of ordered URIs which identifies a chain ofservers through which new requests outside the current dialog should besent. A route set can be learned, through headers like Record-Route, orit can be configured. For UAS 110 the route set is obtained from theheader information of the message 126 and comprises:

-   -   Route Set:        -   P3        -   P2        -   UAC;comp

Thus new requests within the same call sent from the UAS 110 to the UAC102 will be sent via the route provided in the route set. However, thisonly applies for new requests, and not for messages sent in response toprior requests.

The UAS 110 responds to the received INVITE message by sending aresponse 200 OK message 128 back to the UAC 102. SIP requires thatresponse messages follow the same path taken by corresponding requestmessages, and this is assured by sending the response 128 to the nexthop address indicated in the top of the Via list of message 128, in thiscase the proxy 108. Since UAS 110 does not support compression themessage is sent in uncompressed form.

The proxy 108 receives the message 128, removes it's URI from the listof Via headers and forwards the message 130 uncompressed to the proxy106.

When the proxy 106, which is a stateful proxy, receives the responsemessage 130 the proxy determines whether the received message is part ofthe current transaction. This can be achieved, for example, by matchinga transaction identifier for the current message with the informationstored in the transaction context. If the message is part of the currenttransaction, the proxy then analyzes the received message to determinewhether it record-routed. The term record-routed is used herein, as wellas in the SIP specification, to refer to a SIP element that haspreviously inserted a Record-Route header into a SIP message within thesame transaction.

If the proxy 106 did record-route the proxy inspects the route which isset for this dialog. The route comprises in this case: UAS 102, proxy108, proxy 106 and UAC 102. The proxy 104 is not included in the routesince it did not Record-Route. The proxy 106 checks the next downstreamelement in the route (in this case the UAC 102), to determine whether itsupports compression. This may be achieved by determining whether thecompression parameter is present in the URI of the UAC 102.

Since the URI of the UAC 102 in the Contact header of message 130contains the comp parameter, thereby indicating that the UAC supportsSIP compression requests, the proxy 106 adds its own compressionparameter to an appropriate part of the message. In this case this isachieved by modifying its Record-Route header of message 132 to includethe comp parameter.

When the UAC receives the message 134, the UAC constructs a route setthrough the header information contained in the received message, theroute set comprising:

Route Set:

-   -   -   P2;comp        -   P3        -   UAS

The fact that the route set entry for proxy 106 includes the compressionparameter enables the UAC to send further requests within the samedialog in compressed format, as will be seen below.

The UAC 102, processes the received message 134 and responds by sendingan ACK message back to the UAS 110. RFC 3261 specifies that an ACKmessage forms part of a new transaction, and therefore it does not haveto follow the same path as the initial INVITE message, and thus the ACKis sent directly to the proxy 106 in compressed format.

The proxy 106 forwards the message in uncompressed format to proxy 108,which in turn forwards the message to the UAS 110, in the normal manner.

Thus it can be seen that in order to implement SIP message compressionin the prior art requires a transaction context data store to bemaintained in each proxy which supports SIP compression. Additionally, aproxy must also determine, by analyzing message headers, whether anotherelement in the response path supports compression. Furthermore, since aSIP proxy server which supports compression must be transactionstateful, the resource requirements in the SIP proxy are directlyproportional to the number of simultaneous established transactionsbeing handled by the same system.

An embodiment according to the present invention which enables a SIPproxy server supporting compression to be stateless will now bedescribed, with reference to FIG. 2.

FIG. 2A represents a similar SIP network and message flow to that shownin FIG. 1A and like features and messages have been given the samenumerical identifiers. The SIP network comprises a SIP user agent client(UAC) 102, three SIP proxy servers 104, 202 and 108 respectively, and aSIP user agent server (UAS) 110. The proxy server 202 will be describedin more detail below.

FIG. 2B shows a message flow diagram outlining the message flow of a SIPtransaction involving various elements of a SIP network, including a SIPproxy 202 according to an embodiment of the present invention.

The transaction starts with the UAC 102 sending an INVITE message 120 toa UAS 110 via a SIP network comprising the proxy servers 104, 202 and108.

The message 120 is initially sent to a proxy server 104 the address ofwhich is preconfigured in the UAC 102. The Contact header of the INVITEmessage 120 contains the URI of the UAC 102. In this example, the UAC102 supports SIP message compression so the UAC 102 adds the parametercomp to its URI in the Contact header.

The UAC 102 set the Via header of the message 120 to the URI of the UAC102. Since the UAC does not, at this stage, know whether the proxy 104supports compression, the message 120 is sent uncompressed.

SIP proxy 104, which does not support SIP compression and is thusstateless, receives the INVITE message 120 and forwards the message,after having added its URI to the list of Via headers, to the SIP proxy202.

SIP proxy 202, which supports SIP compression, receives the INVITEmessage 122. Proxy 202 is configured to stay in the path of futurerequests in the same SIP dialog and so adds a RECORD-ROUTE headercontaining its URI to the message. However, unlike the proxy 106 asdescribed above, proxy 202 is stateless—in other words it does notmaintain a transaction context and therefore does not require anycontext storage means. The operation of proxy 202 is described belowwith reference to FIG. 3.

When a message is received by the proxy 202 (step 302) the proxydetermines (step 304) whether the message is a request or a responsemessage. If, as in this case, the received message is a request message,the proxy finds the Record-Route header (that the proxy 202 just addedto the message) (step 312) containing its URI in the message, and adds(step 314) a new compression parameter thereto. The new compressionparameter comprises an identifier to unambiguously identify the proxy202, and a compression flag indicating whether or not futures requestsshould be compressed. The unambiguous identifier may be derived in anumber of different ways, which will be apparent to those skilled in theart.

The value of the flag is determined by the proxy 202 in the followingmanner. The proxy 202 analyses the received message to determine whetherthe next upstream element supports SIP compression. The next upstream(i.e. towards to the UAC) element may be determined by first determiningthe presence of the top-most record-route header (if any exists) in themessage, since if any element has record-routed any new request messageswill automatically go through the element which record-routed. If thereis no record-route header this implies that the next upstream element isthat defined by the Contact header of the received message. Once the URIof the next upstream element has been established, the proxy 202analyses the URI thereof to determine the presence of the compparameter. If the comp parameter is present, this indicates that futurerequest messages sent between the next upstream element and the proxy202 may be sent in compressed form. Accordingly, the proxy 202 sets thevalue of the flag to indicate that compression should be used, otherwisethe flag is set to indicate that compression should not be used. At thispoint, however, the record-route parameter for the proxy 202 does notcontain the comp parameter.

Finally, the proxy 202 adds its URI to the list of Via headers, andforwards the message 210 uncompressed to the SIP proxy 108, since againproxy 106 does not initially know if proxy 108 supports compression.

It should be noted that the unambiguous identifier and the flag are onlyinserted to the message if the proxy is configured to stay in the path,for example by being configured to add a record-route header.

SIP proxy 108, which does not support compression, receives the INVITEmessage 210 and, as it too wishes to stay in the path for futurerequests in the same dialog, adds a RECORD-ROUTE header containing itsURI to the message, adds the message details to a transaction contextdata store and adds its URI to the top of the list of Via headers. Themessage is sent to UAS 110 uncompressed since the proxy 108 does notknow if the UAS supports SIP compression.

The UAS 110 receives and processes the message 212. Since the INVITEmessage is the first message of a call, the UAS 110 stores a route setas part of the current call context. For UAS 110 the route set isobtained from the header information of the message 126 and comprises:

-   -   Route Set:        -   P3        -   P2:ID+FLAG        -   UAC;comp

Thus new requests within the same call sent from the UAS 110 to the UAC102 will be sent via the route provided in the route set.

The UAS 110 then sends a response 200 OK message 128 back to the UAC102. As previously mentioned, SIP requires that response messages followthe same path taken by corresponding request messages, and this isassured by sending the response 214 to the next hop address indicated inthe top of the Via list of message 214, in this case the proxy 108.Since the next hop address does not contain the comp parameter, themessage is sent uncompressed.

The proxy 108 receives the message 214, removes it's URI from the listof Via headers and forwards the message 216 uncompressed to the proxy202.

When the proxy 202 receives (step 302) the message 216, and referringagain to FIG. 3, the proxy determines (step 304) whether the receivedmessage 216 is part of a request or a response. In this case, thereceived message is a response message—in other words the receivedmessage is part of a transaction which includes the initial requestINVITE message. The proxy 202 therefore examines the message to find therelevant header of the next downstream element in the route (i.e. theUAC) and searches the received message for the presence of itsunambiguous identifier mentioned above. Such a search routine can beoptimized for speed and efficiency due to the simple nature of thesearch required.

If the identifier of the proxy 202 is found in the message, the value ofthe flag is obtained. In this case the flag indicates, as describedabove, that future request messages should be compressed, and that thenext downstream element supports compression. The proxy 202 thereforemodifies its Record-Route entry in the message 216 to remove thepreviously added unambiguous identifier and flag and replaces it withthe comp parameter. The modified message 218 is then forwarded to theproxy 104.

Those skilled in the art will be aware that in SIP the notion of‘upstream’ and ‘downstream’ is always taken with reference to themessage flow direction of the current request or response.

When the UAC receives the message 134, the UAC constructs a route setthrough the header information contained in the received message, theroute set comprising:

-   -   Route Set:        -   P2;comp        -   P3        -   UAS

The UAC 102 processes the received message 134 and responds by sendingan ACK message back to the UAS 110. Since proxy 202 has Record-Routedand the Record-Route header indicates that the proxy 202 supports SIPcompression, the message 136 is sent directly to the proxy 106 incompressed format. The ACK message 136 is forwarded to the UAS 110 viathe proxy 108 in uncompressed format, as shown in messages 138 and 140respectively.

To summarize SIP compression provides a mechanism by which a sourceelement (such as a UAC) may request that an intermediate element (suchas a proxy) indicates to the source element whether the source elementmay use compression when sending future request messages to theintermediate element. Since SIP only provides a one-way communicationpath, i.e. either a request or a response, such an indication can onlybe given in a response message. According to the present embodiment sucha mechanism advantageously does not require the use of a statefulintermediate element.

The effect of above process is that the 200 OK message 134 received bythe UAC 102 is the identical to that received in the prior art exceptthat, unlike in the prior art which required the use of stateful proxyservers, the present embodiment requires only the use of stateless proxyservers. Thus, SIP proxy servers according to the above-describedembodiment may be deployed in SIP networks which require support of SIPmessage compression, allowing full advantage to be taken of thealready-mentioned benefits of using stateless as opposed to statefulproxy servers.

Those skilled in the art will appreciate that the same techniques mayalso be applied to other SIP elements such as back-to-back user agents(B2BUA)

1. A method of communicating information between an intermediate elementand a source element in a message-based communications system in which arequest message is sent from the source element to a destination elementand in response to which a corresponding response message is sent fromthe destination element to the source element, the request and responsemessages being sent via an intermediate element arranged to forward themessages to the appropriate element, comprising, at the intermediateelement: prior to forwarding a received request message: determining thepresence, in the received request message, of an indication of theinformation to be communicated and where present, adding a temporaryidentifier associated with the intermediate element to the message insuch a way that the temporary identifier is included in thecorresponding response message; and prior to forwarding a receivedresponse message: determining the presence of a temporary identifierassociated with the intermediate element and, where present, replacingthe temporary identifier with the information to be communicated to thesource element.
 2. The method of claim 1, wherein the step of adding thetemporary identifier further comprises adding an identifier whichunambiguously identifiers the intermediate element.
 3. The method ofclaim 1, wherein the step of adding the temporary identifier furthercomprises adding additional information for identifying the type ofinformation to be communicated to the source element.
 4. The method ofclaim 1, wherein the message-based communication system is a sessioninitiation protocol (SIP) based system, wherein the intermediate elementis a SIP proxy server, wherein the request message is a SIP requestmessage, wherein the response message is a SIP response message, andwherein the step of determining the presence in the received requestmessage further comprises determining the presence of a SIP compressionparameter.
 5. The method of claim 4, wherein the request messageincludes the URI of the SIP proxy server, and wherein the step of addingthe temporary identifier further comprises adding the temporaryidentifier to the URI of the SIP proxy.
 6. The method of claim 5,wherein the step of determining the presence of the temporary identifierin a response message further comprises determining the presence of thetemporary identifier in the URI of the SIP proxy within the responsemessage.
 7. The method of claim 6, wherein the step of replacing thetemporary identifier further comprises replacing the temporaryidentifier with a SIP compression parameter.
 8. The method of claimsclaim 4, further comprising sending future request messages from thesource element to the SIP proxy using compression where the SIP proxyhas previously indicated to the source element that the proxy supportsSIP compression.
 9. An intermediate element adapted for operating inaccordance with claim
 1. 10. A SIP proxy adapted for operating inaccordance with claim
 1. 11. Apparatus for forwarding messages in amessage-based communications system in which a request message is sentfrom a source element to a destination element and in response to whicha response message is sent from the source element to the destinationelement, the system being arranged such that messages are sent via theapparatus for forwarding to their appropriate destination, comprising:means for, prior to forwarding a received request message, determiningin the received request message the presence of an indication of theinformation to be communicated, said means being arranged for, where thepresence of the indication is determined, adding a temporary identifierassociated with the intermediate element to the message in such a waythat the temporary identifier is included in the corresponding responsemessage; and means for, prior to forwarding a received response message,determining in the received response message the presence of a temporaryidentifier associated with the intermediate element, said means beingarranged for, where the presence of the temporary identifier isdetermined, replacing the temporary identifier with the information tobe communicated to the source element.
 12. The apparatus of claim 11,wherein the means for adding the temporary identifier is adapted foradding an identifier which unambiguously identifies the intermediateelement.
 13. The apparatus of claim 11, wherein the means for adding thetemporary identifier is adapted for adding additional information foridentifying the type of information to be communicated to the sourceelement.
 14. The apparatus of claim 11, wherein the message-basedcommunication system is a session initiation protocol (SIP) basedsystem, wherein the intermediate element is a SIP proxy server, whereinthe request message is a SIP request message, wherein the responsemessage is a SIP response message, and wherein the means for determiningthe presence in the received request message is adapted for determiningthe presence of a SIP compression parameter.
 15. The apparatus of claim14, wherein the request message includes the URI of the SIP proxy, andwherein the means for of adding the temporary identifier is adapted foradding the temporary identifier to the URI of the SIP proxy.
 16. Theapparatus of claim 15, wherein the means for determining the presence ofthe temporary identifier in a response message is adapted fordetermining the presence of the temporary identifier in the URI of theSIP proxy within the response message.
 17. The apparatus of claim 16,wherein the means for replacing the temporary identifier is adapted forreplacing the temporary identifier with a SIP compression parameter.